fix: pin all Graphile ecosystem RC versions and sync inconsistencies#741
fix: pin all Graphile ecosystem RC versions and sync inconsistencies#741pyramation merged 2 commits intomainfrom
Conversation
- Remove ^ prefix from all RC version specifiers (dangerous for pre-release) - Sync @dataplan/json: 1.0.0-rc.4 -> 1.0.0-rc.5 in root pnpm override - Sync graphile-config: 1.0.0-rc.3 -> 1.0.0-rc.5 in graphql/types - Sync postgraphile: 5.0.0-rc.4 -> 5.0.0-rc.7 in graphile-postgis, graphile-upload-plugin, graphile-plugin-connection-filter-postgis Affected packages (14 total): @dataplan/json, @dataplan/pg, @graphile-contrib/pg-many-to-many, @graphile/simplify-inflection, grafast, grafserv, graphile-build, graphile-build-pg, graphile-config, graphile-utils, pg-sql2, postgraphile, postgraphile-plugin-connection-filter, tamedevil
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
| "pnpm": { | ||
| "overrides": { | ||
| "@dataplan/json": "1.0.0-rc.4" | ||
| "@dataplan/json": "1.0.0-rc.5" |
There was a problem hiding this comment.
🔴 pnpm lockfile not regenerated: @dataplan/json override still resolves 1.0.0-rc.4 instead of 1.0.0-rc.5
The package.json override for @dataplan/json was changed from 1.0.0-rc.4 to 1.0.0-rc.5, but the pnpm-lock.yaml was not regenerated. The lockfile still contains '@dataplan/json': 1.0.0-rc.4 in the overrides section (line 8) and resolves 1.0.0-rc.4 throughout all transitive dependencies.
Impact and root cause
The entire purpose of this PR is to pin Graphile ecosystem RC versions for consistency. However, without regenerating the lockfile:
- Running
pnpm install --frozen-lockfile(standard in CI) will fail because the specifier inpackage.json(1.0.0-rc.5) doesn't match the lockfile specifier (1.0.0-rc.4). - Running
pnpm installwithout--frozen-lockfilewill regenerate the lockfile, but the actual resolved version may differ from what was tested. - The
@dataplan/jsonoverride is used by@dataplan/pgand flows transitively intographile-build-pg,postgraphile, and all Graphile plugins, so the wrong version propagates everywhere.
The lockfile shows on line 8: '@dataplan/json': 1.0.0-rc.4 while package.json:51 specifies "@dataplan/json": "1.0.0-rc.5".
Prompt for agents
Run `pnpm install` to regenerate the pnpm-lock.yaml file so that it reflects the @dataplan/json override change from 1.0.0-rc.4 to 1.0.0-rc.5 in package.json line 51. The lockfile must be committed as part of this PR. Verify that the lockfile overrides section shows @dataplan/json: 1.0.0-rc.5 and that all transitive resolutions reference rc.5 instead of rc.4.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "dependencies": { | ||
| "@graphile-contrib/pg-many-to-many": "2.0.0-rc.1", | ||
| "graphile-utils": "^5.0.0-rc.5", | ||
| "graphile-utils": "5.0.0-rc.5", |
There was a problem hiding this comment.
🔴 pnpm lockfile not regenerated: graphile-utils resolves 5.0.0-rc.6 despite being pinned to exact 5.0.0-rc.5
Both graphile/graphile-misc-plugins/package.json and graphql/server/package.json pin graphile-utils to exact version 5.0.0-rc.5 (no ^), but the lockfile was not regenerated and still shows specifier: ^5.0.0-rc.5 with a resolved version of 5.0.0-rc.6.
Impact and root cause
The lockfile for graphile-misc-plugins (around line 237) and graphql/server (around line 1098) both show:
graphile-utils:
specifier: ^5.0.0-rc.5
version: 5.0.0-rc.6(...)
But the package.json files now specify the exact version "graphile-utils": "5.0.0-rc.5" (without ^). This means:
pnpm install --frozen-lockfilewill fail because specifiers don't match (^5.0.0-rc.5in lockfile vs5.0.0-rc.5in package.json).- The currently locked version (
5.0.0-rc.6) differs from the intended pinned version (5.0.0-rc.5), which is a version downgrade that the PR doesn't account for. - This defeats the stated purpose of the PR: to pin exact RC versions for reproducibility.
The same stale-lockfile problem applies to all the other ^-to-exact changes across the peerDependencies in all modified package.json files, but graphile-utils is the most impactful since the resolved version actually differs.
Prompt for agents
Run `pnpm install` to regenerate the pnpm-lock.yaml file so that it reflects all the version pinning changes across the modified package.json files. In particular, verify that graphile-utils resolves to exactly 5.0.0-rc.5 (not 5.0.0-rc.6) in both graphile/graphile-misc-plugins and graphql/server lockfile entries. The lockfile must be committed as part of this PR.
Was this helpful? React with 👍 or 👎 to provide feedback.
fix: pin all Graphile ecosystem RC versions and sync across packages
Summary
Removes all
^range prefixes from Graphile/graphfast ecosystem RC version specifiers across 9package.jsonfiles, and fixes three version inconsistencies:@dataplan/json1.0.0-rc.4(root override)1.0.0-rc.5package.jsongraphile-config1.0.0-rc.31.0.0-rc.5graphql/types/package.jsonpostgraphile5.0.0-rc.45.0.0-rc.7graphile-postgis,graphile-upload-plugin,graphile-plugin-connection-filter-postgisAll other RC packages only had their
^prefix stripped (no version change).14 Graphile ecosystem RC packages are now consistently pinned:
@dataplan/json,@dataplan/pg,@graphile-contrib/pg-many-to-many,@graphile/simplify-inflection,grafast,grafserv,graphile-build,graphile-build-pg,graphile-config,graphile-utils,pg-sql2,postgraphile,postgraphile-plugin-connection-filter,tamedevilUpdates since last revision
pnpm-lock.yamlto reflect the@dataplan/jsonoverride change (rc.4→rc.5). The lockfile diff is large (~2.7k insertions, ~7.6k deletions) but the meaningful changes are the@dataplan/jsonversion propagating through transitive dependency resolution chains (e.g.postgraphile,graphile-build-pg,graphile-utils).pnpm buildpasses locally across all workspace packages.Review & Testing Checklist for Human
postgraphilerc.4 → rc.7 bump ingraphile-postgis,graphile-upload-plugin, andgraphile-plugin-connection-filter-postgisdoesn't introduce breaking changes (this is a 3-RC-version jump)graphile-configrc.3 → rc.5 bump ingraphql/typesdoesn't break the types package (2-RC-version jump)@dataplan/jsonrc.5 is the correct target — the root pnpm override hadrc.4butgraphile-settingsalready usedrc.5; confirmrc.5is intendedpnpm buildto verify all packages still compile cleanly after the version changes (passed locally but worth confirming in a clean environment)Notes
graphqlitself (^16.9.0) is intentionally left with^since it is a stable release, not an RCgraphile-postgis(^2.0.0) ingraphile-plugin-connection-filter-postgisis also stable and left with^role "root" does not existinfrastructure issue across all 41 test jobs) — not caused by this change